1. Field of the Invention
Embodiments of the present invention relate generally to network communications and more specifically to a method and system for performing wake-on-LAN functionality in a load balanced environment.
2. Description of the Related Art
Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Performance and reliability are key requirements for modern computer networks. One approach is to create a “team” of network interface cards (“NICs”) to handle the networking needs of a computing device. The team operates in a load-balanced environment to avoid overloading of any one specific NIC on the team and also employs techniques such as “failover” to redirect network traffic from one unreliable NIC to other reliable NICs on the team. These NICs are transparent to the operating system of the computing device, since the operating system only recognizes a single Transmission Control Protocol/Internet Protocol (TCP/IP) binding to the team.
However, problems arise when the Wake-on-LAN (WOL) protocol needs to be performed through the team configuration. To illustrate, FIG. 1 is a simplified block diagram of a computing device 100 with a TCP/IP stack 102, which has a single TCP/IP binding 106 to a team 104 including NIC 110, NIC 114, and NIC 118 in a switch independent load balanced environment. Each NIC is configured with its own unique MAC address, but only one of the three MAC addresses is chosen to represent the team 104. For simplicity, the binding 106 maps an IP address to the MAC address of the team 104. It should however be apparent to a person with ordinary skills in the art to recognize that the team 104 can be configured to have multiple IP addresses while still having one team MAC address. Suppose the NIC 110, NIC 114, and NIC 118 are associated with MAC addresses M1, M2, and M3, respectively. Suppose further that the team 104 is associated with the MAC address M3. To wake up the computing device 100, one typical WOL approach is to either direct or broadcast a “magic” packet, a packet including replicated copies of the MAC address associated with the target computing device to be woken up, to the target computing device. Here, in a team configuration, the magic packet contains multiple copies of the MAC address of the team 104, M3. If WOL unit 120 determines that the MAC address in the magic packet matches the MAC address of the NIC 118, then it causes the computing device 100 to wake up. Alternatively, another WOL approach to wake up the computing device 100 is to direct or broadcast a pattern match packet, a packet including a specific pattern, to the team 104. Here, if the WOL unit 120 finds a match between the pattern in the received packet and the pre-programmed pattern in the NIC 118, then it also causes the computing device 100 to wake up.
One problem occurs if the NIC 118 is in failover (due to a faulty NIC or a down link in the team 104) before or after the computing device 100 enters the low power state. The other NICs in the team 104 do not recognize any of the WOL packets (e.g., magic packets or pattern match packets), because the other NICs only match the WOL packets with their own MAC Addresses, resulting in the computing device 100 continuing to stay in the low power state. Another problem occurs if the NIC 118 is the only NIC with the broadcast filter enabled in the team 104 and the NIC 118 again is in failover after the computing device 100 enters the low power state. Without the normal failover operation, the other NICs in the team 104 ignore any broadcast WOL packet to wake up the computing device 100, and the computing device 100 remains stuck in the low power state.
As the foregoing illustrates, what is needed is a method and system for implementing the WOL protocol in a load balanced environment to address at least the problems set forth above.